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EXPERIENCE  WITH  Q 

IMPLEMENTA  TION  OF  A 
PROTOTYPE  PROGRAMMING  ENVIRONMENT 

PARTI 


Bruce  J.  MacLennan 

Computer  Science  Department 

Naval  Postgraduate  School 

Monterey,  CA  93943 


Abstract: 

This  is  the  first  report  of  a  series  exploring  the  use  of  the  Q  programming  notation  to  prototype  a  pro- 
gramming environment.  This  environment  includes  an  interpreter,  unparser,  syntax  directed  editor, 
command  interpreter,  debugger  and  code  generator,  and  supports  programming  in  a  small  applicative 
language.  The  present  report  describes  the  interpreter,  unparser,  syntax  directed  editor,  command 
interpreter  and  debugger  for  a  subset  of  the  language,  namely  arithmetic  expressions. 


1.    Introduction 

Our  goal  is  to  explore  in  the  context  of  a  very  simple  language  the  use  of  the  Cl  programming  notation 
[MacLennan83,  MacLennan85]  to  implement  some  of  the  tools  that  constitute  a  programming  environ- 
ment.   Succeeding  reports  will  extend  the  tools  described  in  this  report*. 

The  structure  of  this  report  is  as  follows:  First  we  briefly  review  the  fi  programming  notation  for 
describing  transformations  on  relations.  Second,  we  define  a  simple  language  —  the  language  of  arith- 
metic expressions.  An  abstract  syntax  for  this  language  is  defined  in  terms  of  relations.  Third,  we  dis- 
cuss abstract  interpretation  of  programs  in  this  language.  Fourth,  we  modify  the  interpreter  to  accom- 
plish unparsing.  Next,  we  look  at  error  recovery  and  interactive  debugging.  Finally,  we  consider  syntax 
directed  editing  of  abstract  programs. 


Support  for  this  research  was  provided  by  the  Office  of  NavaJ  Research  under  contract  N 00014-85- WR-24057. 
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2.    OVERVIEW  OF  Q 

2.1  Requirements  for  a  Programming  Environment  Database 

To  understand  the  relevance  of  f2  to  programming  environments  we  begin  by  stating  the  requirements 
for  a  software  development  database.  It  will  be  required  to  store  and  interrelate  many  kinds  of  infor- 
mation: 

—  Programs 

—  Specifications 

—  Documentation 

—  Version  Information 

—  Comments 

—  Object  Code 

—  Implementation  Hints 

—  Test  Data 

—  Test  Results 

—  Reports 

—  Runtime  Structures 

In  prototyping  tools  and  environments,  we  want  to  make  a  minimum  of  implementation  commitments. 
Hence,  it  is  convenient  to  take  a  relational  view.  This  is  because  relations  are  a  well-understood, 
implementation-independent  way  of  viewing  databases. 

2.2  RELATIONS 

We  will  view  the  computer  system  (or  network)  as  containing  a  (possibly  large)  number  of  (finite)  rela- 
tions. The  number  of  relations  is  not  fixed;  new  (empty)  relations  can  be  created  by  direct  (user)  or 
indirect  (program)  request.    The  tuples  in  relations  can  contain: 


•  Values:  For  example,  numbers.  Booleans,  characters,  strings.  "pure':  lists. 

•  Objects:  Essentially  unique  IDs;  their  only  properties  are  the  relations  in  which  they  participate. 
Relations  are  themselves  objects. 

2.3    Notation 

We     use     the     notation     lR  [x,y,  .  .  .  ,z) '     to     mean     the     tuple     (x ,y ,  .  .  .  ,  z)     is     in     R .      Similarly, 
'->i?(z,j/;  .  .  .  ,z)'  means  that  there  is  no  such  tuple  in  R . 

Operations  on  the  database  are  described  by  a  kind  of  production  rule: 

cause    =>  effect 

The  effect  part  is  composed  of  a  series  of  transactions.  There  are  two  forms  for  a  transaction: 

•  R  [x  ,y ,  .  .  .  ,  z)  means  add  the  tuple  (x,y,  .  .  .  ,  z)  to  R . 

•  ->R(x,y,  .  .  .  ,  z)  means  delete  the  tuple  from  R . 

The    arguments    x ,  y ,  .  .  .  ,   z    can   be    any   applicative    expressions.     They   can    also    be    procedures,  i.e., 
parameterized  database  transformations. 

The  cause  part  has  the  form: 

condition  ,     •  ■  • 

The  cause  is  a  sequence  of  conditions  separated  by  commas.    Each  condition  asks  whether  certain  rela- 
tions hold  certain  tuples. 

The  condition  l R  (x  ,y ,  .  .  .  ,  z) '  succeeds  if  there  is  a  tuple  (x  ,  y ,  .  .  .  ,  z)  in  R .    On  the  other  hand, 
i-R(x  ,y ,  .  .  .  ,zY  fails  if  there  is  such  a  tuple  in  R .    The  arguments  x,  y,  .  .  .  ,   z  have  the  forms: 

•  a  constant  matches  itself; 

•  &  free  variable  matches  anything,  and  becomes  bound  to  value  it  matches. 

•  an  applicative  expression  matches  its  value. 

We   consider  several  examples   of   conditions.     #(2,3)    succeeds   if  the    pair   (2,3)    is  in    R.     -^(2,3) 
succeeds  if  the  pair  (2,3)   isn't  in  R.    If  'y'  is  free  (unbound),  then  R(2,y)  succeeds  if  there  is  a  pair  of 
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the  form  (2.v)  in  R ;  variable  'y'  becomes  bound  to  v .  ~R(2.y)  succeeds  if  there  is  no  pair  of  the 
form  (2,u)  in  R.  If  'y'  is  bound  to  t\  then  5(y.3)  succeeds  if  the  pair  (t',3)  is  in  5.  ^S(y,3) 
succeeds  if  the  pair  (  v  ,3)  is  not  in  S. 

An  implicit  join  is  a  rule  in  which  the  same  free   variable   appears  in  several  conditions.    For  exam- 
ple, 

fl(2,y),  S{y,3) 
succeeds  if: 

1.  There  is  a  pair  of  the  form  (2,t;)  in  R 

2.  The  pair  (v  ,3)  is  in  S 

It  fails,  otherwise.  Note:  There  may  be  many  pairs  of  the  form  (2,f)  in  R .  The  join  succeeds  if  for 
one  or  more  of  them  ( t;  ,3)  is  in  S.    Any  conjunction  of  conditions  is  allowed  in  the  cause. 

2.4    Stack  Example 

To  illustrate  these  ideas  we  show  the  Q  definition  of  a  stack  manager.  First  we  introduce  the  relations 
and  their  intuitive  meanings: 

•  Stack(s)  —    object  s  is  a  stack 

•  Contents(  x  ,s  )  —    the  list  x  is  the  contents  of  s 

•  Push(a,x,«)  —    a  pushes  x  on  s 

•  Pop(a,s)  —    a  pops  s 

•  Receives(  a  ,i )  —    a  receives  x 

The  domains  of  these  relations  are  described  by  the  following  assertions  (second  order  relations).  Thus 
'Degree  (Contents,  2)'  means  that  all  the  tuples  in  Contents  have  two  elements;  'Domain  (list,  1,  Con- 
tents)' means  that  the  first  elements  of  the  tuples  in  Contents  satisfy  the  'list'  predicate;  and  'Indexed 
(Contents,  2)'  means  that  the  second  elements  of  the  tuples  in  Contents  are  all  unique.  Each  assertion 
is  shown  in  two  notations:  the  usual  predicate  notation  and  a  pseudonatural  notation  (H  supports 
several  semantically  equivalent  notations;  see  ( MacLennan84.  Ufford85]). 


•  Degree  (Stack,  1) 
'Stack'  has  degree  1. 

•  Degree  (Contents,  2), 
'Contents'  has  degree  2. 

•  Domain  (list,  1,  Contents) 
'list'  is  domain  1  of  'Contents'. 

•  Domain  (Stack,  2,  Contents) 
'Stack'  is  domain  2  of  'Contents'. 

•  Indexed  (Contents,  2) 
'Contents'  is  indexed  by  domain  2. 

•  Degree  (Push,  3) 
'Push'  has  degree  3. 

•  Domain  (Stack,  3,  Push) 
'Stack'  is  domain  3  of  'Push'. 

•  Degree  (Pop,  2) 
'Pop'  has  degree  2. 

t      Domain  (Stack,  2,  Pop) 

'Stack'  is  domain  2  of  'Pop'. 

•  Degree  (Receives,  2) 
'Receives'  has  degree  2. 

The  pop  rule  describes  how  to  pop  a  stack: 

Stack  (s),  Pop  (a,s),  Contents  (x,s) 

=>     ^Pop  (a,«), 

^Contents  (x  ,s  ) , 
Receive  (a,  first  [i]), 


Contents  (rest  [z] ,  s  ) 

It  can  be  read  as  follows:    "If  s  is  a  stack,  a  is  popping  s.  and  x  is  the  contents  of  s,  then  a  is  not  pop- 
ping s .  x  is  not  the  contents  of  s ,   a  receives  the  first  element  of  r.  and  the  rest  of  x  is  the  contents  of 


s  . 

The  push  rule  is  analogous: 

Stack  («),  Push  (a,x,e),  Contents  (y,s) 

=>     -\Push  (  a  ,x  ,s  ) , 
-Contents  ( y  ,s  ) , 
Receive   (a,«), 
Contents  (cons  [x,y],  s) 

If  «  is  a  stack,  a  is  pushing  i  on  «,  and  y  is  the  contents  of  s,  then  a  is  not  pushing  x  on  s,  y  is  not 
the  contents  of  s ,  a  receives  «,  and  the  result  of  consing  x  on  1/  is  the  contents  of  «. 

2.5    Further  Notational  Conventions 

Notice  that  in  the  push  and  pop  rules,  conditions  found  to  hold  in  the  cause  parts  of  rules  are  often 
canceled  in  the  effect  parts.  Since  this  is  a  very  common  situation  we  introduce  the  following  cancella- 
tion convention:  When  a  tuple  found  in  the  condition  is  removed  by  the  effect,  i.e.,  a  relation  that  holds 
in  the  condition  is  canceled  by  the  effect,  we  can  indicate  this  by  an  '*'  before  the  condition.  For 
example,  the  pop  and  push  rules  can  be  written: 

Stack(s),    *Pop(a,«),   *Contents(  x  ,s  ) 

=s>     Receive)  a,  6rst[zj),  Contents(rest{  x  ] ,  s) 

Stack(s),    *Push(  a  ,x  ,s) ,   *Contents(  y  ,s  ) 
=s>     Receive  (  a  ,«) ,  Contents(cons[  x  ,y] ,  s) 

It  is  often  useful  to  limit  the  application  of  rules  by  constraints,  which  are  implemented  as  follows.  The 
relation  called  'if  contains  the  single  value  true.  Hence,  an  applicative  expression  that  evaluates  to  a 
Boolean  value  can  be  used  to  constrain  rule  application.    For  example: 


Sched  (x,t),  Clock  (0-  ^  {t>  t)    => 

For  convenience  we  often  omit  the  if  and  write: 

Sched  {x,t),  Clock  [t),  t>  t    =?> 

We  can  summarize  all  that  we've  seen  in  the  following  (simplified)  grammar  for  the  fi    language: 

Simplified  fi    Grammar 

rule  =   [cause   =>  j    effect 

cause        =  cond  ,     ■  -  ■ 


m.d  rel  args 


args  =   (  expr  ,     ■  •  •    ) 

effect        =  trans  ,    •  •  • 
trans         =  [->]   rel  args 

A  complete  fi    grammar  can  be  found  in  [  MacLennan85] . 

2.6   Pseudonatural  Notation 

We  have  experimented  with  several  pseudonatural  notations  for  fi  rules.  The  notation  used  in  this 
report  is  a  variation  of  that  described  in  [MacLennan84]  and  [Ufford85J.  Relations  can  be  named  by 
templates,  for  example: 

—  is  stack 

—  is  contents  of  — 

—  pops  — 

—  pushes  —    on  — 

—  receives  — 

Rules  are  written: 

If  -    the  n  - 
with  ','  or  ',   and'  for  ','.    The  word  'given'  represents  the  cancellation  convention  '*'.    Hence  the  pop 
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rule  can  be  written: 

If  5  is  stack,  given  A  pops  5.  and  given  X  is  contents  of  S 
then  A  receives  first  of  X.  and  rest  of  X  is  contents  of  5. 

The  push  rule  is: 

If  S  is  stack,  given  A  pushes  A'  on  5,  and  given   Y  is  contents  of  5 
then  A  receives  5  and  catenation  of  X  and   Y  is  contents  of  5. 

Allowing  'a'    'an'  and  'the'  as  noise  words  and  using  words  for  variable  names  we  have: 

If  an  object  is  a  stack,  given  an  agent  pops  the  object,  and  given  a  list  is  the  contents  of  the  object 
then  the  agent  receives  the  first  of  the  list,  and  the  rest  of  the  list  is  the  contents  of  the  object. 

If  an  object  is  a  stack,  given  an  agent  pushes  a  thing  on  the  stack,  and  given  a  list  is  the  contents  of 
the  stack  then  the  agent  receives  the  stack,  and  the  catenation  of  the  thing  and  the  list  is  the  con- 
tents of  the  stack. 
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S.    Abstract  Structure 

For  our  example   programming  environment  we  will  use   a  very  simple   language  of  arithmetic  expres- 
sions composed  of  -K  — ,  x,  -f,  parentheses  and  literal  integers.    A  typical  program  is: 

(3+5)   x  6 

First  we  must  define  an  abstract  structure  for  representing  programs.    There  are  two  kinds  of  nodes: 

•  Constant  Nodes:    correspond  to  literals. 

•  Application  Nodes:    correspond  to  the  application  of  an  operator  to  its  operands 
These  nodes  and  their  interconnections  can  be  represented  by  the  relations: 

.      Con  (E) 

E  is  a  constant 

.      Litval  (  V,  E) 

V  is  the  literal_yalue  of  E. 

•  Appl(£) 

E  is  an  application. 

.     0V{F,E) 

F  is  the  operator  of  E. 

.      Left  (X,  E) 

X  is  the  left_argument  of  E. 

.     Right  (  Y,  E) 

Y  is  the  right_argument  of  E. 
For  example,  the  program 

(3+5)   x  6 

would  be  represented  by  the  database: 


Appl  (nl) 
Op  ("x",  nl) 
Left  (n2,  nl) 
Right  (n3.  nl) 

Appl  (n2) 
Op  ("+'*,  n2) 
Left  (n4,  n2) 
Right  (n5,  n2) 

Con  (n3) 
Litval  (6,  n3) 
Con  (n4) 
Litval  (3,  n4) 
Con  (n5) 
Litval  (5,  n5) 

Meaning  (sum,  "+  ") 
Meaning  (product,  "x") 

We  have  given  the  objects  names  ('nl',  'n2',  etc.)  only  so  they  can  be  referred  to  in  our  example;  nor- 
mally they  would  be  anonymous  since  the  tree  would  have  been  constructed  by  an  editor.  This  data- 
base is  portrayed  in  Figure  1. 

In  defining  the  domains  of  the  various  relations,   it  will  be  convenient  to  make  use  of  the  following 
function  abbreviation.    Let  'Function(  F.D,R  ) '  mean 

.      Degree(F,2), 

•      Domain(i?  ,1,F), 

.      Domain(Z>,2,F), 

.      Indexed(F,2). 

In  the  pseudonatural  notation  we  can  say: 
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Appl  ^J^ 

Op^^-^X      \ 

"x'V-"^"        /  Left 

XRight 

Appl    x^ 

CnnNt 

Jsf\   n2 
j^/      \ 

n3 

"  +  '>^        /Left\     Right 

Litval 

Cnn      ,*            Con    \ 

Litval 

Litval 

6 

3                        5 

Figure  1.    Database  Representing  Abstract  Program 

'F  is  a  function  from  D  to  R'  means 

lF  has  degree  1,  R  is  domain  1  of  F,  D  is  domain  2  of  F,  and  F  is  indexed  on  domain  2'. 

Hence,   if  we  know  that  Function(  F,D,R ) ,   that  is,   that  F  is  a  function  from   D   to  R  ,  then  we  know 
that  given  any  z  in  D  there  will  be  at  most  one  y  such  that  F{y,x). 

The  domains  of  the  abstract  program  structure  relations  (in  the  pseudonatural  notation)   are  as  fol- 
lows: 

'constant'  has  degree  1. 

'literal  value'  is  a  function  from  'constant'  to  'integer'. 

'application'  has  degree  1. 

'operator'  is  a  function  from  'application'  to  'string'. 

'left_argument'  is  a  function  from  'application'  to  'expression'. 

'right_argument'  is  a  function  from  'application'  to  'expression'. 
In  the  predicate  notation  this  is: 


Degree  (Con,  1) 

Function  (litval,  Con,  integer) 

Degree  (Appl,  1) 

Function  (Op,  Appl,  string) 
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Function  (Left,  expr,  expr) 
Function  (Right,  expr,  expr) 

Here  we  have  assumed  that 


expr  =    Con  U    Appl 
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4.    Evaluation 


4.1    Relations 


The  preceding  relations  define  the  abstract  program  structure;  they  are  static  (with  respect  to  program 
evaluation).  We  need  additional  relations  to  control  program  evaluation;  they  are  dynamic  (with  respect 
to  program  evaluation).    The  evaluation  relations  are; 

.      Eval  [E) 

E  is  evaluated 

.      Value  (  V,  E) 

V  is  the  value  of  E 

•  Meaning  ( F,  N) 

F  is  the  meaning  of  N. 
The  domains  of  these  relations  are: 

•  Degree(Eval,l) ,  Domain(expr,l,Eval). 

'evaluated'  has  degree  1,  and  'expression'  is  domain  1  of  'evaluated'. 

•  Function  (Value,  expr.  integer) 

'value'  is  a  function  from  'expression'  to  'integer'. 
Function  (Meaning,  string,  function) 

'meaning'  is  a  function  from  'string'  to  'expression'. 

Eval  and  Value  can  be  thought  of  as  attributes  that  at  various  times  are  attached  to  various  nodes  in  the 
tree.  In  particular,  the  Eval  attribute  on  a  node  means  that  the  evaluation  of  that  node  has  been 
requested,  but  not  serviced.  The  Value  attribute  associates  a  value  with  a  node  until  such  time  as  that 
value  is  used.  The  Meaning  relation  is  a  table  that  maps  the  names  of  operators  into  functions  for  per- 
forming the  operations. 
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4.2    Evaluation  of  Constant  Node 


The  transformation  required  to  evaluate  a  constant  node  can  be  portrayed: 


Con 


E 


Con 


Litval  " 


E 
-9~ 


Litval  -  . 


Value 


That  is,  if  the  Eval  attribute  arrives  at  a  constant  node,  then  we  remove  the  Eval  attribute  (since  the 
request  has  been  serviced),  and  use  a  Value  link  to  bind  the  node's  literal  value  to  the  node.  In  other 
words,  when  an  Eval  arrives  at  a  leaf  of  the  tree  it  is  converted  into  a  Value,  which  will  travel  back  up 
the  tree. 

The  rule  for  accomplishing  this  is  simply1: 

If  given  an  expression  is  evaluated,  the  expression  is  a  constant,  a  number  is  the  literal  value  of  the 
expression,  and  a  function  is  the  meaning  of  "lit" 

then  the  function  of  the  number  is  the  value  of  the  expression. 

This  is  expressed  in  the  predicate  notation  as: 

*Eval(£),  Con(E),  Litval(  V,E),  Meaning(F,"lit")     =*>     Value(F[  V},E) 

The  function  that  is  the  meaning  of  "lit"  is  the  identity  function,  hence  the  following  simpler  rule 
would  also  work: 

*Eval(£),  Con(£),  Litval(  V,E)    =>     Value (  V,E) 

We  have  used  the  more  complicated  rule  to  display  the  symmetry  between  the  evaluator  and  the 
unparser  (which  is  discussed  in  the  following  section). 


1.     The  pseudonatural  transcription  of  the  rules  was  prepared  by  Robert  Ufford;  see  jUfford85] 
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4.3    Evaluation  of  Application  Node 

Evaluation  of  application  nodes  is  accomplished  in  two  steps.  First  there  is  a  downward  analysis  pass 
when  the  Eval  attribute  reaches  the  node  and  is  passed  to  its  daughters.  Later  there  is  an  upward  syn- 
thesis pass  when  the  Values  from  the  daughters  arrive  back  at  the  node  and  are  used  to  compute  the 
Value  for  the  node.    These  steps  can  be  visualized  as  in  Figures  2  and  3. 


Figure  3.    Step  2:    Perform  Operation 


It  is  easy  to  translate  these  diagrams  into  rules.    First  the  analysis  (downward)  rule: 

If  given  an  expression  is  evaluated,  the  expression  is  an  application,  node_l  is  the  left_argument  of 
the  expression,  and  node_2  is  the  right_argument  of  the  expression 

then  node_l  is  evaluated,  and  node_2  is  evaluated. 

In  the  predicate  notation: 

*Eval(£),  Appl(£),  Left(A\£),  Right(  Y,E) 
=^   Ev&\(X),  Eval(F) 

Notice   that  the   Eval  flag  is  passed  to  both  daughters  simultaneously;  thus  they  can  be  evaluated  con- 
currently or  in  any  other  order.    Hence,  Eval  is  a  parallel  evaluator. 

Next  we  consider  the  synthesis  (upward)  rule: 
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If  an  expression  is  an  application,  a  string  is  the  operator  of  the  expression,  node_l  is  the  left  argu- 
ment of  the  expression.   node_2  is  the  right  argument  of  the  expression,   a  function  is  the  meaning 
of  the  string,  given  numberj  is  the  value  of  node_l  and  given  number_2  is  the  value  of  node_2 
then  the  function  of  numberj  and  number_2  is  the  value  of  the  expression. 

In  the  predicate  notation: 

Appl(£),  Op(N,E),  LeH(X,E),  Right(7,£), 
Meaning(J\JV),  *Value(  U,X) ,  *Value(  V,  Y) 

=>   Value  (F  \U,V],  E) 
This  completes  the  parallel  evaluator  for  simple  abstract  arithmetic  expressions. 
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5.    Unparsing 


5.1    Relations 


We   will  now   use    exactly   the    same    approach    as  used   for  evaluation,    but   for  a  different  purpose   — 
unparsing.     Instead   of  computing   an   integer  value  for  the    abstract  program,   we   will  compute   a  string 
value,  which   is   the    program's  concrete   representation.     That  is  we   will   unparse  the   abstract  program. 
This  is  accomplished  by  changing  the  interpretation  of  the  literal  constants  and  the  primitive  operators. 

This  is  a  quite  general  approach.  From  a  single  program  such  as  the  evaluator  we  can  generate  a 
family  of  related  programs,  just  by  changing  the  domain  of  interpretation  of  the  constants  and  operators. 
Examples  of  tools  amenable  to  this  approach  are  unparsers,  type  checkers,  symbolic  evaluators. 

The  following  relations  are  needed: 

•  Unparse  (E) 
E  is  unparsed 
(corresponds  to  Eval) 

•  Image  (5,  E) 

S  is  the  image  of  E 
(corresponds  to  Value) 

.      Template  (  T,  N) 

T  is  the  template  for  N 
(corresponds  to  Meaning) 

Given  our  previous  example,  Unparse(nl)  will  eventually  result  in 

Image  ("( (3+5)  x6)  ",  nl) 

For  simplicity  we  have  generated  an  image  that  is  fully  parenthesized. 

The  domains  of  the  relations  are  as  follows: 

•  Degree  (Unparse,  1) 
'unparsed'  has  degree  1. 
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•  Function  (Image,  expr.  string). 

'image'  is  a  function  from  'expression'  to  'string'. 

•  Function  (Template,  string,  function), 
'template'  is  a  function  from  'string'  to  'function' 

We  also  will  make  the  following  assumptions: 

•  Assume  the  function  'string— int  [n]!  converts  the  integer  n   into  a  string. 

•  Assume  Template  (string— int,  "lit"). 

•  Assume  s  *t  represents  string  catenation. 

•  For  operator  symbols  N,  assume  Template  (F,  N),  where 

F\U,V\  =  "("  *U  ~N  AV  *")" 
and  N  is  "+  "  or  "-"  or  "x"  or  "-=-".    Thus,  if  Template  (F,  "+  "),  then 

F  ["3",  "(6  x  2)"]     =     "(3  +  (6  x  2)" 

5.2  Unparsing  Constants 

When   the   Unparse   attribute   arrives  at  a  constant  node,   the  literal  value   is  converted  to   a  string  and 
made  the  image  of  the  node.    In  the  pseudonatural  notation  the  rule  is: 

If  given  an  expression  is  unparsed,  the  expression  is  a  constant,  a  number  is  the  literal  value  of  the 

expression,  and  a  function  is  the  template  of  "lit" 

then  the  function  of  the  number  is  the  image  of  the  expression. 

In  predicate  notation  it  is: 

*Unparse(£),  Con(£),  Litval(  V,E),  Template)  F,E) 
=>     Image (  F\V\,  E) 

5.3  Unparsing  Applications 

The    arrival   of  the    unparse    attribute    at   an    application    node    triggers    its    propagation    to    the    daughter 
nodes.    Hence  the  analysis  rule  in  pseudonatural  notation  is: 

-18- 


If  given  an  expression  is  unparsed,  the   expression  is  an  application,   node-1   is  the  left_argurnent  of 
the  expression,  and  node_2  is  the  right_argument  of  the  expression 
then  node_l  is  unparsed.  and  node_2  is  unparsed. 

In  predicate  notation  it  is: 

*Unparse(£),  Appl(£),  Left(A\£),  Right(F,£), 
=>    Unparse(X),  Unparse(F) 

When  images  arrive  at  the  daughters  of  the  application,   they  are  combined  by  the  template  function  of 
the  operator  into  an  image  for  the  entire  node.    Hence  the  synthesis  rule  in  pseudonatural  notation  is: 

If  an  expression  is  an  application,  a  string  is  the  operator  of  the  expression,  node_l  is  the 
left_argument  of  the  expression,  node_2  is  the  right_argument  of  the  expression,  a  function  is  the 
template  of  the  string,  given  image_l  is  the  image  of  node_l,  and  given  image_2  is  the  image  of 
node_2 

then  the  function  of  image_l  and  image_2  is  the  image  of  the  expression. 

In  the  predicate  notation: 

Appl(£),  Op{N,E),  Left(A,£),  Right(  Y,E), 

Template^, AT),  *Image(  U, X) ,  *Image(  V,  Y) 
=s>   Image  (F\U,V\,  E) 

This  completes  the  rules  for  the  unparser. 
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6.    Information  Hiding 


The  relations  can  be  divided  into  three  domains  of  accessibility  on  the  basis  of  "need  to  know": 


Abstract 

Programs 

Con,  Litval, 

Appl,  Op, 

Left,  Right 

/          \ 

/ 

Evaluator 

Unparser 

Eval, 

Unparse, 

Value, 

'  Image, 

Meaning 

Template 

That  is,  both  the  evaluator  and  the  unparser  need  access  to  the  abstract  structure  relations  (read-only 
access,  actually).  On  the  other  hand,  the  evaluator  needs  access  to  its  own  dynamic  relations,  but  not 
to  those  of  the  unparser.  Conversely,  the  unparser  needs  access  to  its  own  relations,  but  not  the 
evaluator's.  These  access  restrictions  can  be  enforced  by  the  capability  mechanism  described  in 
!  MacLennan85l . 
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7.    Error  Handling 

7.1    Error  Detection 

A  real  programming  environment  must  be  able  to  detect  errors  and  allow  the  user  to  deal  with  them. 
Let's  consider  what  happens  when  an  error  occurs.  Suppose  we  evaluate  ((3-=-0)  +  l).  This  leads  to  the 
assertion 

Value  (quotient  [3,0],  n) 

Suppose  quotient) 3, Oj   =>    error.    This  will  trigger  that  assertion 

Value  (sum  [error, lj,  m) 

If  we  further  assume  sum[error,l]  =>  error,  then  the  value  returned  for  the  entire  evaluation  is 
'error'.  This  result  is  not  helpful  —  it  doesn't  tell  us  where  the  error  occurred,  only  that  an  error 
occurred. 

One  possible  solution  is  to  suppose  the  primitive  operations  return  "error  codes"  when  something 
goes  wrong,  that  the  code  indicates  what  went  wrong,  and  that  error  codes  are  distinguishable  from 
integers  and  other  "legitimate"  values.  Then  we  can  incorporate  error  checking  into  our  interpreter. 
We  do  this  by  tentatively  attaching  the  alleged  value  to  the  node  (via  a  new  relation  called  Check)  until 
it  is  determined  whether  or  not  the  value  is  legitimate.    This  requires  the  following  additional  relations: 

.      Check  (  V,  E) 

V  is  the  value  to  be  checked  for  E 

•  Explanation  (5,   C) 

S  is  the  explanation  of  error  C 

•  Display  ( 5) 

S  is  displayed 

•  CurrentNode  (E) 

E  is  the  current  node 
The  domains  of  these  relations  are: 
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Function  (Check,  expr,  integer). 
Function  (Explanation,  errorcode.  string), 
Degree  (Display,  1). 
Domain  (string.   1.  Display) 

We  then  need  to  modify  the  second  (upward  or  synthesis)  rule  for  applications.  It  is  replaced  by  these 
three  rules: 

Appl(£),  Op(N,E),  Left{X,E),  Right  (  Y,E), 
Meaningf  F,N),  *Value(  U,X),  "Value (  V,  Y) 
=^>    Check  (F  \U,  V],  E). 

*Check(  W,E),  if  (integer}  W\)  =->   Value(  W,E). 

*Check(  ^,-E),  Explanation^,  FP), 

*CurrentNode(-  ),  if  (errorcodef  W\) 
=>   Display {5},  CurrentNode(£) . 

The  first  rule  tentatively  attaches  F{  U,V\  to  the  application  node  via  Check.  If  the  value  of  F'[  U,  V]  is 
an  integer,  then  the  second  rule  converts  the  Check  connection  to  a  Value  connection  to  reflect  the  fact 
that  the  value  is  bona  fide.  On  the  other  hand,  if  the  value  of  F\  U,V]  is  an  error  code,  then  evalua- 
tion is  stopped  (since  no  Value  is  attached  to  the  node),  the  offending  node  is  recorded  (in 
CurrentNode) ,  and  an  explanation  of  the  error  code  is  displayed. 

In  the  pseudonatural  notation  these  rules  are: 

If  an  expression  is  an  application,  a  string  is  the  operator  of  the  expression,  node_l  is  the 
left_argument  of  the  expression,  node_2  is  the  right_argument  of  the  expression,  a  function  is  the 
meaning  of  the  string,  given  numberj  is  the  value  of  node_l,  and  given  number_2  is  the  value  of 
node_2  then  the  function  of  numberj  and  number_2  is  the  value  to  be  checked  for  the  expression. 

If  given  an  alleged_yalue  is  the  value  to  be  checked  for  an  expression,  and  the  alleged_yalue  is  an 
integer  then  the  alleged_yalue  is  the  value  of  the  expression. 
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If  given  an  alleged  value  is  the  value  to  be  checked  for  an  expression,  the  alleged_yalue  is  an 
error  code,  a  string  is  the  explanation  of  the  error^rode,  and  any_node  is  the  current_node  then  the 
string  is  displayed,  and  the  expression  is  the  current_node. 

Thus,  if  an  erro-  value  is  detected,  evaluation  is  suspended,  an  error  message  is  issued,  and  the 
offending  node  is  recorded.- 

The  alert  reader  will  realize  that  with  a  parallel  evaluator  there  is  the  possibility  of  several  errors 
occuring  concurrently.  With  the  error  checking  method  presented  above,  all  the  diagnostics  will  be 
issued  correctly,  but  CurrentNode  will  record  only  the  last  node  to  generate  an  error.  A  more  elaborate 
system  would  place  all  error  nodes  in  a  two  place  relation  ErrorNodes  such  that 

ErrorNodes  [E,C) 

means  that  node  E  generated  error  code  C .  It  is  then  necessary  to  have  a  command  for  removing  a 
node  from  ErrorNodes  and  making  it  the  CurrentNode.  The  detailed  implementation  is  left  as  an  exer- 
cise for  the  reader. 

7.2    Suspension 

What  is  the  state  when  an  error  message  is  sent?  There  may  be  parallel  computations  in  progress,  but 
since  no  Value  has  been  provided  for  E,  the  evaluation  cannot  complete.  It  is  suspended,  waiting  for  a 
value  for  E. 

There  are  several  possible  actions: 

1.  Supply  a  value  for  the  offending  node  and  let  evaluation  continue.    E.g.  , 

CurrentNode  [E)     =*>     Value  (0,E); 

2.  Unparse  the  offending  node  to  find  the  problem: 

CurrentNode  (E)     =s>     Unparse  (E); 

CurrentNode  (E),  *Image  [S,E)     =^>     Display  {5}; 


2.     We  show  the  rule  that  would  be  typed  in  fi    command  mode  to  effect  the  desired  error  recovery  action. 
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3.  Investigate  neighboring  nodes  (e.g..  the  divisor): 

*CurrentNode  (E),  Right  (  Y,E)     =s>     CurrentNode  (  Y); 

—    un parse  as  above 

4.  Reevaluate  the  dividend  and  supply  a  default  value  for  the  divisor.    E.g., 

CurrentNode  (£),  Left  (X,E)    =s>     Eval  [X); 

CurrentNode  (E),  Right  (Y,E)     =>     Value  (1,  Y); 

5.  Abort  evaluation  by  clearing  out  all  Eval,  Value  and  Check  tuples: 

*Eval  [E)    =^>     ; 
*Value  (V,E)    =^>     ; 
*Check  (V,E)    =*>     ; 

All  these  functions  (and  more)  could  be  provided  as  commands  in  a  programming  environment.    In  the 
next  section  we  will  investigate  a  command  interpreter  that  permits  debugging  actions  such  as  these. 
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8.    Command  Interpreter 

In  this  section  we  will  describe  a  simple  command  interpreter  in  fi  rules.  This  command  interpreter 
will  permit  the  interactive  evaluation  and  unparsing  of  (already  entered)  abstract  programs,  in  addition 
to  various  debugging  and  error  recovery  activities. 

We  assume  the  existence  of  a  relation  called  Command  that  contains  the  last  string  or  keystroke  (we 
don't  care  which)  typed  on  the  keyboard.  We  will  use  boldfaced  identifiers  such  as  evaluate  to 
represent  commands;  these  identifiers  could  be  bound  to  strings,  key  codes,  menus  coordinates,  etc. 

First  we  consider  the  evaluate  command:  its  intended  effect  is  to  request  evaluation  of  the  current 
expression,  which  might  be  the  entire  program  or  some  subexpression  of  it.  This  command  is  imple- 
mented by  the  following  two  rules: 

*Command  (evaluate),  CurrentNode(.E')    =>     Eval  (E),  Pendant  {E). 

*Pendant  (E),  *Value  {V,E)    =^>     Display  {strings  int  [V]}. 

The  first  rule  detects  the  evaluate  command  and  requests  evaluation  of  the  expression.  That  an  evalua- 
tion is  in  progress  is  recorded  in  the  Pendant  relation.  When  a  value  arrives  at  the  pendant  node,  it  is 
displayed  by  the  second  rule. 

The  auxiliary  relation  Pendant  can  be  eliminated  by  using  H  's  sequential  mechanism: 

*Command  (evaluate),  CurrentNode  (E) 
=->   {Eval  (E); 

*Value  (  V,E)     =>     Display  {string-  int  [V]}  }. 

The  commands  in  the  curly  braces  are  evaluated  in  order.  Thus  the  tuple  is  asserted  to  Eval  before  the 
second  rule  waits  for  a  tuple  in  Value. 

The  val  command  is  used  to  explicitly  attach  a  value  to  a  node.  This  might  be  used  during  error 
recovery  to  allow  evaluation  to  proceed  in  the  face  of  errors.  The  command  makes  use  of  an  additional 
relation  Argument  which  holds  a  string  value  typed  in  from  the  keyboard.  We  can  imagine  this  work- 
ing as  follows:    The  user  types  '254'  and  strikes  the  val  key.    This  causes  the  string  "254"  to  be  put  ji 
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the  Argument  relation  and  the  key  val  to  be  put  in  the  Command  relation.    The  rule  for  processing  the 
val  command  is: 

*Command(val),  *Argument(  V) ,  CurrentNode  (£) 
==>    Value  (int«-  string  [  V\,E). 

The   show  command  requests  the  current  expression  to  be  unparsed  and  displayed.    It  is  implemented 
by: 

*Command  (show),  CurrentNode  [E) 
=>    {  Unparse  (E); 

*Image  (S,E)     =>     Display  {S}}. 

It  is  also  useful  to  have  commands  for  moving  within  the  abstract  program  structure.    The  in  command 
"zooms  in"  by  focusing  on  the  left-argument  of  the  current  expression: 

*Command  (in),  *CurrentNode  (E),  Left  (X,E) 
=>    CurrentNode  {X). 

Thus  the  in  command  shifts  the  focus  from  the  current  node  to  the  leftr- argument  of  the  current  node. 

The  next  command  shifts  the  focus  from  the  left  argument  of  an  application  to  its  right  argument: 

*Command  (next),  "CurrentNode  (X),  Left  (X,E),  Right  (  Y,E) 
=>    CurrentNode  (  Y) . 

In  the  pseudonatural  notation  this  is  expressed: 

If   given    next  is   the   command,    node_l    is   the    current_node,    node_l    is    the    left_argument   of  an 
appl_node,  and  node_2  is  the  right_argument  of  the  appl_node  then  node_2  is  the  current_node. 

Analogous   commands   are   prev,   which   shifts   from   the   right  argument  to   the   left  argument,   and  out 
which  "zooms  out"  from  either  the  left  of  right  argument  to  the  entire  application. 

For  debugging  it  is  useful  to  be  able  to  abort  a  suspended  evaluation.    This  is  accomplished  by  clear- 
ing out  the  Eval,  Check  and  Value  relations: 
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Command  (abort),  *Eval  (E)    => 

else  Command  (abort),  *Check  (  V,E)     =s> 

else  Command  (abort).  *Value  (  V,E)    =s> 

else  *Command  (abort)     =>     Display  {"aborted."}. 

Notice  (by  the  absence  of  an  '*')  that  the  first  three  rules  leave  abort  in  command;  hence  they  continue 
firing  as  long  as  there  are  tuples  in  Eval,  Check  or  Value.  When  there  are  no  more  such  tuples,  the  last 
rule  cancels  the  abort  command. 

It  could  be  argued  that  these  rules  would  be  more  readable  if  the  reassertion  of  abort  were  made 
explicit,  e.g., 

*Command  (abort),  *Eval  (E)    =>     Command  (abort) 
else  *Command  (abort),  *Check  (  V,E)     =s>     Command  (abort) 
else  *Command  (abort),  *Value  (  V,E)     ==>     Command  (abort) 
else  *Command  (abort)     =>     Display  {"aborted."}. 

This  is  an  unresolved  stylistic  issue. 

To  illustrate  the  operation  of  the  command  interpreter,  we  present  an  example  session,  showing  the 
keys  typed  and  the  responses  of  the  system.  Assume  the  program  '((3—0)  +  l)'  is  already  created  and 
the  current  node  is  the  root  of  the  tree.    The  transcript  follows: 

evaluate 

zero  divide  error 
show 

(3-0) 
in 

evaluate 
next 
show 

0 
1  val 
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Notice  how  the  vaJ  command  triggers  completion  of  evaluation  of  the  program. 
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9.    Syntax  Directed  Editing 

9.1  Incomplete  Programs 

In  this  section  we  develop  a  syntax  directed  editor  for  this  simple  language.  Since  for  editing  we  need 
to  be  able  to  represent  incomplete  programs  we  will  add  a  new  node  type,  'Undef,  representing  a  part 
of  the  program  that  either  has  not  yet  been  entered  or  has  been  deleted: 

expr  =   Con  U    Appl  U     Undef 

Next  we  must  modify  Eval  and  Unparse  to  deal  with  L  ndef  nodes: 

*Eval(£),  Undef(£),  *CurrentNode(- )  =*   Display{"Incomplete"},  CurrentNode(£) . 

*Unparse(£'),  Undef(E)  ==>    Image  ("<  expr>  ",  E) . 

In  other  words,  evaluating  an  incomplete  program  will  lead  to  a  diagnostic  message  and  a  suspended 
evaluation.  Unparsing  an  incomplete  program  will  show  '<expr>  '  in  place  of  the  missing  subexpres- 
sion. 

9.2  Editor  Commands 

What  commands  do  we  want?    We  will  want  in  to  "zoom  in"  on  a  subexpression: 


We  will  want  out  to  "zoom  out"  from  a  subexpression: 


We  will  want  next  to  shift  to  the  next  (to  the  right)  subexpression: 


We  will  want  prev  to  shift  to  the  previoEs  (to  the  left)  subexpression: 
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It  will  be  convenient  to  have  root  to  shift  to  the  root  of  the  program  tree: 


Furthermore,  we  will  want  all  of  these  movement  commands  to  show  us  the  new  current  expression  by 
un parsing  it. 

We  will  also  need  a  begin  command  to  initialize  the  editing  session  with  an  empty  tree: 


0 


iL)ide( 


We  will  want  to  be  able  to  delete  a  node: 


*££> 


/ 


linJief 


And  we  will  want  to  be  able  to  insert  a  literal  value,  by  'n  #': 


U-rvW 


(c. 


rt 


t 

Finally  we  will  need  the  operator  commands,  -+-  ,  — ,   x,  -r,  for  creating  application  nodes: 


These  are  all  simple  to  implement. 

The  predicate  form  for  the  in  command  rule  is: 

*Command(in),  *CurrentNode(£),  Left(*,£) 
==>    CurrentNode(  X) ,  Co  mm  and  ( show) . 

This   is  the  same   as  the   version   discussed    ,n   the   previous  section,   except  that  we   have   automatically 
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issued  a  show  command. 

In  the  pseudonatural  notation  the  in  rule  is: 

If    given    "in"    is    the    command,    given    an    expression    is    the    current_node,    and    a    node    is    the 

left_argument  of  the  expression 

then  the  node  is  the  current_node,  and  "show"  is  the  command. 

The  out  command  is  analogous,  except  that  there  are  two  rules  to  handle  the  two  possible  paths  back  to 
the  parent: 

*Command(out),  *CurrentNode(X),  Left(X,E) 
=>   CurrentNode(i?) .  Command  (show). 

*Command(out),  *CurrentNode(  F),  Right(  Y,E) 
==>    CurrentNode(.E') ,  Command  (show). 

The  next  and  prev  commands  are  similar. 

The  delete  command  is  implemented  by  breaking  the  current  node's  connections  with  its  descen- 
dants and  changing  its  type  to  Undef.  There  are  three  cases  depending  on  whether  the  node  is  a  con- 
stant, application  or  already  undefined  node: 

*Command(delete),  CurrentNode(£),  *Con(£),  *Litval(  V,E) 
=s>    Undef(.E'),  Command(show) . 

*Command(delete),  CurrentNodeJi?), 

*Appl(£),  *Op{N,E),  *Leh{X,E),  Right(  Y,E) 
=>    Undef  (E) ,  Command(show) . 

*Comm  and  (delete),  CurrentNodeJi;) ,  Undeff^) 
=>    Display  {"already  deleted"}. 

Note  that  subtrees  are  not  disassembled;  hence  they  could  be  reused  (say  by  a  move  command). 

There  are  two  rules  to  implement  the  #  command.  The  first  one  is  to  create  a  constant  node  with  a 
given  literal  value: 
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*Command("#"),  *Argument(  V) ,  if  ( integerf  V) ) ,  CurrentNode(£) .  *Undef(£) 
=>    Con(E),  Litvalf  V,E) ,  Command(show). 

The  other  rule  handles  the  case  where  the  current  node  is  already  defined;  we  require  a  node  to  be 
deleted  before  it  can  be  replaced: 

*Command("#"),  *Argument(  V) ,  CurrentNodef  E) ,  -Undef(£) 
=>    Display  {"defined  node"}. 

Next  we  consider  that  commands  for  creating  application  nodes.  If  the  user  types  '+  '  then  we  must 
create  an  Appl  node  with  two  undefined  daughters  and  a  '+  '  for  the  operator: 

*Command("+"),  *CurrentNode(£) ,  *Undef(£),  *Avail(X,  Y) 
=>   Appl(£),  Op("+",£),  Left(J,£),  Right(  Y,E), 
Undef(X),  Undef(F),  CurrentNode(X). 

Here  we  have  assumed  that  Avail  contains  an  indefinite  supply  of  unused  objects;  objects  are  allocated 
by  a  system  procedure  in  the  McArthur  interpreter.  Also  notice  that  the  focus  is  automatically  shifted 
to  the  left  argument  of  the  new  application. 

It  would  be  somewhat  inconvenient  to  repeat  the  above  rule  for  each  of  the  four  operators.  Also  we 
would  need  four  rules  for  detecting  already  defined  nodes.  Fortunately  we  can  use  the  applicative 
features  of  fl   to  make  one  rule  handle  all  four  operators: 

*Command(/),  member  [/,  ["+  ",  "-",  "x",  "-r"]]f 

*CurrentNode(£),  *Undef(£),  *Avail(.Y,  Y) 
=^>    Appl(£),  0p(/,£),  Left(X,E),  Right(F,£),  Undef(X),  Undef(F),  CurrentNode(  X) . 

Already  defined  nodes  are  handled  by: 

*Command(/),  member  [/,  ["  +  ",  "-",  "x",  "-=-"]],  CurrentNode(£) ,  -Undef(E) 
=o    Display{"defined  node"}. 

The  begin  command  is  implemented  by  creating  a  tree  containing  a  single  undefined  node: 

*Co  mm  and  (begin),  *CurrentNode(-  ),  *Avail(£")  =>    Rooi{E),  Undef(£   . 
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The   root  command   is  simple  since   the   Root  relation   holds   the  root  of  the   tree   (set  by  the  begin 
command) : 

"Command (root),  *CurrentNode(-  ),  Root(£") 
=>    CurrentNode(.E') ,  Command(show) . 

A  typical  session  will  illustrate  operation  of  the  syntax  directed  editor.  Our  goal  will  be  to  construct  the 
program  '  (3-rO)  +1'  and  change  it  to  '  (3-M)  -t-1'.  We  show  commands  on  the  left  margin,  and  responses 
indented: 

begin 
<  expr> 


3# 
next 

<  expr> 
0# 

out 

(8+0) 
out 

((3-rO)  +  <  expr> 
in 

(3-0) 
next 

<  expr> 
1  # 
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root 

((3-r0)  +  l) 

evaluate 

zero  divide  error 
show 

(3-0) 
in 

3 
next 

0 
delete 

1  # 
root 

((3-S-1J+1) 
abort 

aborted. 
evaluate 
4 

This  is,  of  course,  a  very  simple  system  for  a  very  simple  language.  But  it  illustrates  the  ideas  of  a  pro- 
gramming environment.  A  version  of  this  system  that  executes  correctly  under  the  McArthur  inter- 
preter [McArthur84]  is  shown  in  the  appendices. 

9.3    Permissions 

We  review  the  access  to  the  various  relations  needed  by  the  various  tools: 

•  Editor  —    can  read  and  update   program  structure  relations   (Con,   Litval,  etc.),   CurrentNode,   Root 
and  evaluator  and  un parser  relations  (Eval,  Check,  Value,  Unparse,  Image). 

•  Evaluator  —     can   only   read   program   structure   relations;   can   read   and   update   evaluation   relations 
(Eval,  Check  and  Value);  can  update  CurrentNode  and  Display;  can  read  Meaning  and  Explanation. 
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•      Unparser   —     can    only    read   program    structure    relations;    can   read   and    update    unparser   relations 

(Unparse  and  Image);  can  read  Template. 
These  rights  can  be  enforced  using  the  Q    capability  mechanism;  see    MacLennan83  i  or  [MacLennan85j 
for  a  description. 

10.  Conclusions 

We  believe  that  this  report  has  shown  that  major  components  of  a  programming  environment,  albeit  in 
a  rudimentary  form,  can  be  conveniently  programmed  in  Q  .  If  this  experience  is  typical,  if  a  reason- 
able programming  environment  can  be  prototyped  in  a  few  hundred  rules,  then  we  believe  that  our 
ability  to  prototype  software  will  have  been  much  enhanced.  Succeeding  reports  in  this  series  will 
further  investigate  this  hypothesis  by  expanding  the  capabilities  of  the  prototype  programming  environ- 
ment. 
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APPENDIX  A:    Prototype  Programming  Environment 
Predicate  Notation  for  fi 

The  following  is  a  loadable  input  file  for  the  prototype  programming  environment  described  in  this 
report.  It  is  accepted  by  the  McArthur  interpreter  [McArthur84j ,  which  differs  in  a  few  details  from 
the  Q  described  in  this  report  (see  [  MacLennan84J ).  A  transcript  of  a  test  execution  of  this  environ- 
ment is  shown  in  Appendix  C. 

!  PI-1 

!  Rules  and  associated  definitions  for 

!  an  arithmetic  expression  language. 

!  Relations 

!    Program  Structure  Relations 

define  {root,  "Appl",  newrel{}}; 

define  {root,  "Op",  newrel{}}; 

define  {root,  "Left",  newrel{}}; 

define  {root,  "Right",  newrel{}}; 

define  {root,  "Con",  newrel{}}; 

define  {root,  "Litval",  newrel{)}; 

!    Evaluation  Relations 

define  {root,  "Eval",  newrel{}}; 

define  {root,  "Check",  newrel{}}; 

define  {root,  "Value",  newrel{}}; 

define  {root,  "Meaning",  newrel{)}; 

define  {root,  'Explanation",  newrel{}}; 

!    Unparser  Relations 

-36- 


define  {root,  "Unparse",  newrel{}}; 
define  {root,  'Image",  newrel{}}; 
define  {root,  'Template",  newrel{}}; 


!    Command  Interpreter  Relations 

"Command",  newrel{}}; 
"Argument",  newrel{}}; 
"Root",  newrel{}}; 
"Undef",  newrelfl}; 
"CurrentNode",  newrel{}}; 

"EvalPending",  newrel{}}; 
"ShowPending",  newrel{}}; 
"Create Appl",  newrel{}}; 
"Create Root",  newrel{}}; 
'Script",  newrel{}}; 
"PendScript",  newrel{}}. 


define 

root, 

define 

root, 

define 

root, 

define 

root, 

define 

root, 

define  ■ 

root, 

define  ■ 

root, 

define  < 

root, 

define  ■ 

root, 

define  - 

root, 

define  - 

root, 

!  Functions 

fn  Id  [xj :  x; 

fn  Sum  [x,y]:  x  +   y; 

fn  Dif  [x,y] :  x  -  y; 

fn  Product  [x,yj:  x  *  y; 

fn  Quotient  [x,y]: 

if  y  =   0  ->    ["error",  1] 

else  x  /  y; 

fn  IsErrorcode  Iwl: 
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if  "IsListjwj  |  w  =   Nil  ->    Nil 
else  firstlw]   =    "error"; 

fn  upSum  jx,y[:  "("  +   x  +    "  +    "  +    y-    ") "; 
fn  upDif  jx.yi:  *'("  +   x  +    "  -  "  +   y  +    ") "; 
fn  upProd  [x,y]:  "("  +   *  +    "x"^    y+    ") "; 
fn  upQuot  [x,y]:  "("  +   x  +    »'/"  +    y  +    ")". 

!  Built-in  Tables 

Meaning  (Sum,  "■+  "); 
Meaning  (Dif,  "-"); 
Meaning  (Product,  "x"); 
Meaning  (Quotient,  "/"); 
Meaning  (Id,  "lit"); 

Template  (upSum,  "+  ") ; 

Template  (upDif,  "-"); 

Template  (upProd,  "x"); 

Template  (upQuot,  "/"); 

Template  (int_str,  'lit"); 

Explanation  ("incomplete  program",  ["error",  0]); 
Explanation  ( ''division  by  zero",  ["error",  lj). 

!  the  Rules 

define{root,  "PIlRules", 

<  < 

!  Evaluator  Rules 

!  Constant  nodes 
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if  *Eval(e):  Con(e).  Litval(v,e).  Meajning(f.  "lit") 
->    Value(f  j  v, .  e) ; 

!  Appl  nodes 

if  *Eval(e),  Appl(e),  Left(x,e),  Right(y,e) 
->    Eval(x),  Eval(y); 

if  *Value(u,x),  *Value(v,y),  Appl(e),  Op(n,e),  Left(x.e).  Right(y,e),  Meaning(f,  n) 
->    Check(f[u,v] ,  e); 

!  Error  Checking 

if  *Check(w,  e),  ~IsErrorcode[  w] 
->    Value(w,  e) ; 

if  *Check(w,  e),  IsErrorcodejw] ,  Explanation(s,  w),  *CurrentNode(q) 
->    displayn{s},  CurrentNode(e) ; 

!  Unparser 

!  Constant  Nodes 

if  *Unparse(e),  Con(e),  Litval(v,e),  Template (f,  'lit") 
->    Image(f[  v] ,  e) ; 

!  Identifier  nodes 

!  Appl  nodes 

if  *Unparse(e),  Appl(e),  Left(x,e),  Right(y,e) 
->    Unparse(x),  Unparse(y); 

if  *Image(u,x),  *Image(v,y),  Appl(e),  Op(n,e),  Left(x,e),  Right(y,e),  Template  (f.  n) 
->    Image(f[u,v],  e); 
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!    Command  Interpreter  Rules 

!    evaluate  Command 

if  *Command(  "evaluate").  CurrentNode(E) 
->    Eval(E),  EvalPendmg(E); 

if  *Value(V,E).  *EvalPending(E) 
->    displayn  {V}; 

!    return  Command 

if  *Command("val"),  *Argument(V) ,  CurrentNode(E) 
->    Value(V.E); 

!    show  Command 

if  *Command("show"),  CurrentNode(E) 
->    Unparse(E),  ShowPending(E) ; 

if  *Image(S,E),  *ShowPending(E) 
->    displayn {S}; 

!    abort  Command 

if  Commandf  "abort"),  *Eval(E)  ->    ; 

if  Command("abort"),  *Value(V,E)  ->    ; 

if  Command  ("abort"),  *Check(V,E)  ->    ; 

if  *Co  mm  and  ("abort"),  "Eval(E),  "Value  (V,E)  ->    displayn  {"aborted"}; 

!    Handle  incomplete  program 

if  *Eval(E),  Undef(E),  *CurrentNode(Q) 
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->    displayn(  "Incomplete").  CurrentNode  (E) : 

if  *Unparse(E).  Undef(E) 
->    Image  (  "<  expr>  ",  E); 

!    Syntax  Directed  Editing 

!    in  Command 

if  *Co  mm  and  ("in"),  *CurrentNode(E) ,  Left(X,E) 
->    CurrentNode  (X) ,  Com mand(  "show") ; 

if  *Command("out"),  *CurrentNode(X),  Left(X,E) 
->    CurrentNode (E),  Command("show"); 

if  *Command("out"),  *CurrentNode(  Y) ,  Right(Y,E) 
->    CurrentNode (E),  Command)  "show"); 

!    next  Command 

if  *Command("next"),  *CurrentNode(X) ,  Left(X,E),  Right(Y,E) 
->    CurrentNode)  Y) ,  Command("show"); 

!    prev  Command 

if  *Command("prev"),  *CurrentNode(  Y) ,  Right(Y,E),  Left(X.E) 
->    CurrentNode(X) ,  Command)  "show") ; 

!    delete  command 

if  *Comm  and)  "delete"),  CurrentNode(E),  *Con(E),  *Litval(V,E) 
->    Undef(E),  Command) "show"); 

if  *Command(  "delete"),  CurrentNode(E),  *Appl(E),  *Op(N,E),  *Left(X.E),  Right(Y.E) 
->    Undef(E),  Command  ("show"); 
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if  *Command(  "delete"),  CurrentNode(E),  Undef(E) 
->    displayn ("already  deleted") ; 

!    #  Command 

if  *Command("#"),  *Argument(  V) ,  IsInt[V],  CurrentNode(E) ,  *Undef(E) 
->    Con(E),  Litval(V,E),  Command('^how"); 

if  ^CommandC^"),  *Argument(V) ,  CurrentNode(E) ,  "Undef(E) 
->    displayn  ("defined  node") ; 

!    +  ,  -,  x  ,  /  Commands 

if  *Command(op),  member  [op,  ["+",  "-",  "x",  "/"]],  *CurrentNode(E) ,  *Undef(E) 
->    Create Appl(op,  E,  newobj{},  newobj{}); 

if  *CreateAppl(op,E,X,Y) 

->    Appl(E),  Op(op,E),  Left(X,E),  Right(Y,E),  Undef(X),  Undef(Y),  CurrentNode(X): 

if  *Command(op),  member  (op,  ["+",  "-",  "x",  "/"]],  CurrentNode(E),  ~Undef(E) 
->    displayn  ("defined  node"); 

!    begin  Command 

if  *Command( "begin"),  *CurrentNode(Q) 
->     CreateRoot(newobj{}); 

if  *CreateRoot(E) 

->    Root(E),  Undef(E),  CurrentNode(E); 

!    root  Command 

if  *C>mmand('¥oot"),  *CurrentNode(Q) ,  Root(E) 
->    CurrentNode(E) ,  Command('!show"); 
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!    Test  Driver 

if  *Script(Nil)  ->    displayn{"Script  completed"} 

else  if  *Script(L),  ( first!  L]=  "#"  j  first[L!=  'Val") 
->    {  displayn  {"..." -f    first  [rest  [L]  ]  ■+-    first  jL]}; 

Command(first[Lj ) ,  Argument(firstirest(L]  ] ),  PendScript(rest[restjL]  j )   } 

else  if  *Script(L) 

->    {displayn  {"  ...  "  +    first  |L]}; 

Command(first[Lj ) ,  PendScript(restiL] )   }; 

if  *PendScript(L),  Xommand(Q)  ->    Script(L) 

>>    }. 

define  {root,  "testscript", 

["begin",  "+  ",  "/",  "#",  3,  "next",  "#",  0,  "out",  "out", 
'in",  "next",  "#",  1,  'Voot",  "evaluate",  '%how",  "in", 
"next",  "delete",  "#",  1,  'Voot",  "abort",  "evaluate"]   }. 

!  activate  the  rules 

act{  PIlRules  }. 

CurrentNode(Nil). 
displayn{"PI-l  System  loaded"}. 
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APPENDIX  B:    Prototype  Programming  Environment 
Pseudo natural  Notation  for  Q 

This  appendix  displays  the  prototype  programming  environment  of  Appendix  A  in  the  pseudonatural 
notation  designed  by  Robert  Ufford  !  Ufford85] .  Ufford  also  performed  this  translation  of  the  Appendix 
A  program  into  the  pseudonatural  notation. 


PI-1 

Rules  and  associated  definitions  for 
an  arithmetic  expression  language. 


!       Relations      ! 

!      Program  structure  relations      ! 

'Application"  (procedure)  is  defined  as  a  relation. 
"Operator"  (procedure)  is  defined  as  a  relation. 
"Left_argument"  (procedure)  is  defined  as  a  relation. 
'Right_argument"  (procedure)  is  defined  as  a  relation. 
"Constant"  (procedure)  is  defined  as  a  relation. 
"Literal_yalue"  (procedure)  is  defined  as  a  relation. 

!      Evaluation  relations      ! 

"Evaluated"  (procedure)  is  defined  as  a  relation. 
"Checked"  (procedure)  is  defined  as  a  relation. 
"Value"  (procedure)  is  defined  as  a  relation. 
"Meaning"  (procedure)  is  defined  as  a  relation. 
"Explanation"  (procedure)  is  defined  as  a  relation. 
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!      Unparser  relations      ! 

"Unparsed"  (procedure)  is  denned  as  a  relation. 
"Image"  (procedure)  is  defined  as  a  relation. 
'Template"  (procedure)  is  defined  as  a  relation. 

!      Command  interpreter  relations      ! 

"Command"  (procedure)  is  defined  as  a  relation. 
"Argument"  (procedure)  is  defined  as  a  relation. 
"Root_node"  (procedure)  is  defined  as  a  relation. 
"Undefined"  (procedure)  is  defined  as  a  relation. 
"Current_node"  (procedure)  is  defined  as  a  relation. 

"Pending_e valuation"  (procedure)  is  defined  as  a  relation. 
"Shown"  (procedure)  is  defined  as  a  relation. 
"New_application"  (procedure)  is  defined  as  a  relation. 
"New_root"  (procedure)  is  defined  as  a  relation. 
"Script"  (procedure)  is  defined  as  a  relation. 
"Pending_script"  (procedure)  is  defined  as  a  relation. 

!      Functions     ! 
function  identity  [x]:  x. 
function  sum  |x,y]:  x  +    y. 
function  difference  [x,y]:  x  -  y. 
function  product  [x,y]:  x  *  y. 
function  quotient  [x,y]: 

if  y  =    0  then  the_list  of  the  "error_code"  and  1 

else  x  /  y. 

function  error_code  [W]: 
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if  W  (predicate)  is  not  a_list    W  =    Nil  then  Nil 
else  the  first  (function)  of  W  =    "error_code". 

function  sum_template  [x,y]:  "( "  —    x  —    "—    "  -+■   y  +  •")". 
function  difference_template  [x,y]:  "( "  —    x  +    "-"-)-    y  -+    ") ". 
function  product_template  jx.yj:  "("-)-    x  +    "x  " -r   y  +    ") ". 
function  quotient__template  [x,yj:  "( "  +    x  +    "/"+   y  +    ") ". 

!      Built-in  tables      ! 

Sum  is  the  meaning  of  "+  ". 
Difference  is  the  meaning  of  "-". 
Product  is  the  meaning  of  "x". 
Quotient  is  the  meaning  of  "/". 
Identity  is  the  meaning  of  "lit". 

Sum_template  is  a  template  for  "-+■  ". 
Difference_template  is  a  template  for  "-". 
Product_template  is  a  template  for  "x". 
Quotient_template  is  a  template  for  "/". 
String_notation  is  a  template  for  "lit". 

"Incomplete  program"  is  an  explanation  for  the_list  of  error_code  and  0. 
'Division  by  zero"  is  an  explanation  for  the_list  of  error_code  and  1. 

!      Noise  words     ! 

"Must"  (procedure)  is  defined  as  a  noise_yerb. 
"Be"  (procedure)  is  defined  as  a  noise_yerb. 
"Being"  (procedure)  is  defined  as  a  noise_yerb. 
"Established"  (procedure)  is  defined  as  a  noise_yerb. 
"Will"  (procedure)  is  defined  as  a  noise_yerb. 
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"Another"  (procedure)  is  denned  as  a  noise_prep. 

!      The  rules      ! 

"PIl_rules"  (procedure)  are  defined  as 
Rules 

!      Evaluator  rules      ! 

!      Constant  nodes      ! 

If  given  an  expression  is  being  evaluated, 

the  expression  is  a  constant, 

a  number  is  the  literal_yalue  of  the  expression,  and 

a  lit_function  is  the  meaning  of  "lit" 
then  the  lit_function  (function)  of  the  number  is  the  value  of  the  expression; 

!      Application  nodes      ! 

If  given  an  expression  is  being  evaluated, 

the  expression  is  an  application, 

nodel  is  the  left_argument  of  the  expression,  and 

node2  is  the  right^axgument  of  the  expression 
then  nodel  must  be  evaluated,  and 

node2  must  be  evaluated; 

If  given  value  1  is  the  value  of  nodel, 
given  value2  is  the  value  of  node2, 
the  expression  is  an  application, 
a  string  is  the  operator  of  the  expression, 
nodel  is  the  left_argument  of  the  expression, 
node2  is  the  right_argument  of  the  expression,  and 
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an  operator_function  is  the  meaning  of  the  string 
then  the  operator_function  (function)  of  value]  and  value2  must  be  checked 
for  the  expression; 

!      Error  checking     ! 

If  given  an  alleged_yalue  is  being  checked  for  an  expression,  and 

the  alleged_yalue  (predicate)  is  not  an  error_code 
then  the  alleged_yalue  is  the  value  of  the  expression; 

If  given  an  alleged_yalue  is  being  checked  for  an  expression, 

the  alleged_yalue  (predicate)  is  the  error_code, 

a  string  is  an  explanation  for  the  alleged_yalue  ,  and 

given  any_node  is  the  current_node 
then  the  string  (procedure)  is  displayed_with_return  and 

the  expression  is  the  current_node; 

!      Unparser     ! 

!      Constant  Nodes     ! 

If  given  an  expression  is  being  unparsed, 

the  expression  is  a  constant, 

value  1  is  the  literal_yalue  of  the  expression,  and 

a  lit_function  is  a  template  for  'lit" 
then  the  lit_function  (function)  of  value  1  is  the  image  of  the  expression; 

!      Identifier  nodes      ! 

!      Application  nodes      ! 

If  given  an  expression  is  being  unparsed, 
the  expression  is  an  application. 
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nodel  is  the  left_argument  of  the  expression,  and 
node2  is  the  right_argument  of  the  expression 
then  nodel  must  be  unparsed  and 
node2  must  be  unparsed; 

If  given  imagel  is  the  image  of  nodel, 
given  image2  is  the  image  of  node2, 
the  expression  is  an  application, 
a  string  is  the  operator  of  the  expression, 
nodel  is  the  left_argument  of  the  expression, 
node2  is  the  right_argument  of  the  expression,  and 
an  operator_function  is  a  template  for  the  string 

then  the  operator_f  unction  (function)  of  imagel  and  image2 
is  the  image  of  the  expression; 

!      Command  interpreter  rules      ! 

!      Evaluate  command      ! 

If  given  "evaluate"  is  the  command,  and 

an  expression  is  the  current_node 
then  the  expression  must  be  evaluated,  and 

the  expression  is  pending_evaluation; 

If  given  valuel  is  the  value  of  an  expression,  and 

the  expression  is  pending_evaluation 
then  valuel  (procedure)  is  displayed_with_return; 

!      Return  command      ! 

If  given  "val"  is  the  command, 

given  valuel  is  the  argument,  and 
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an  expression  is  the  current _node 
then  value  1  is  the  value  of  the  expression; 

!      Show  command      ! 

If  given  "show"  is  the  command,  and 

an  expression  is  the  current_node 
then  the  expression  must  be  unparsed,  and 

the  expression  will  be  shown; 

If  given  a  string  is  the  image  of  an  expression,  and 

given  the  expression  must  be  shown 
then  the  string  (procedure)  is  displayed_with_return; 

!      Abort  command      ! 

If  "abort"  is  the  command,  and 

given  an  expression  is  being  evaluated 
then  !do  nothing!  . 

If  "abort"  is  the  command,  and 

given  a_yalue  is  the  value  of  an  expression 
then  !do  nothing!  . 

If  "abort"  is  the  command,  and 

given  a_yalue  is  being  checked  for  an  expression 
then  !do  nothing!  . 

If  given  "abort"  is  the  command, 

an  expression  is  not  being  evaluated,  and 
a_yalue  is  not  the  value  of  the  expression 

then  "aborted"  (procedure)  is  displayed_with_return; 
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!      Handle  incomplete  program      ! 

If  given  an  expression  is  being  evaluated, 

the  expression  is  undefined,  and 

given  any_node  is  the  current_node 
then  "Incomplete"  (procedure)  is  displayed_with_return,  and 

the  expression  is  the  current_node; 

If  given  an  expression  is  being  unparsed,  and 

the  expression  is  undefined 
then  "<  expr>  "is  the  image  of  the  expression; 

!      Syntax  Directed  Editing     ! 

!     in  Command     ! 

If  given  "in"  is  the  command, 

given  an  expression  is  the  current_node,  and 
nodel  is  the  left_argument  of  the  expression 

then  nodel  is  the  current_node,  and 
'^show"is  the  command; 

If  given  'but"  is  the  command, 

given  nodel  is  the  current_node,  and 
nodel  is  the  left_argument  of  an  expression 

then  the  expression  is  the  current_node,  and 
'!show"is  the  command; 

If  given  'but"  is  the  command, 

given  node2  is  the  current_node,  and 

node2  is  the  right_argument  of  an  expression 

then  the  expression  is  the  current_node,  and 
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"show"  is  the  command; 
!      next  Command      ! 

If  given  "next"  is  the  command. 

given  nodel  is  the  current_node, 

nodel  is  the  left_argument  of  an  expression,  and 

node2  is  the  right_argument  of  the  expression 
then  node2  is  the  current_node,  and 

"show"  is  the  command; 

!      prev  Command      ! 

If  given  "prev"  is  the  command, 

given  node2  is  the  current_node, 

node2  is  the  right_argument  of  an  expression,  and 

nodel  is  the  left_argument  of  the  expression 
then  nodel  is  the  current_node,  and 

"show"  is  the  command; 

!      delete  command     ! 

If  given  "delete"  is  the  command, 
an  expression  is  the  current_node, 
given  the  expression  is  a  constant,  and 
given  a_yalue  is  the  literal_yalue  of  the  expression 

then  the  expression  is  undefined,  and 
"show"  is  the  command; 

If  given  "delete"  is  the  command, 
an  expression  is  the  current_node, 
given  the  expression  is  an  application, 
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given  a  string  is  the  operator  of  the  expression, 
given  nodel  is  the  left_argument  of  the  expression,  and 
node2  is  the  right_argument  of  the  expression 
then  the  expression  is  undefined,  and 
"show"  is  the  command; 

If  give  "delete"  is  the  command, 

an  expression  is  the  current_node,  and 

the  expression  is  undefined 
then  "already  deleted"  (procedure)  is  displayed_with_return; 

!      $  Command      ! 

If  given  "#"  is  the  command, 

given  value  1  is  the  argument, 

valuel  (predicate)  is  an_integer, 

an  expression  is  the  current_node,  and 

given  the  expression  is  undefined 
then  the  expression  is  a  constant, 

valuel  is  the  literal_value  of  the  expression,  and 

"Ishow"  is  the  command: 

If  given  "#"  is  the  command, 

given  valuel  is  the  argument, 

an  expression  is  the  current_node,  and 

the  expression  is  not  undefined 
then  "defined  node"  (procedure)  is  displayed_with_return; 

!      -f  ,  -,  x,  /  Commands 

If  given  a  string  is  the  command, 
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the  string  is  a  member  of  thejist  of  "+  ",  "-",  "xM,  and  "/", 
given  an  expression  is  the  current_n ode,  and 
given  the  expression  is  undefined 
then  the  expression  is  established  as  a  new_application  with  a  string 
and  an  object  and  another  object; 

If  given  an  expression  is  a  new_application  with  a  string  and  nodel 

and  node2 
then  the  expression  is  an  application. 

the  string  is  the  operator  of  the  expression, 

nodel  is  the  left_argument  of  the  expression, 

node2  is  the  right_argument  of  the  expression, 

nodel  is  undefined, 

node2  is  undefined,  and 

nodel  is  the  current_node; 

If  given  a  string  is  the  command. 

the  string  is  a  member  of  the  Jist  of  "+  ",  "-",  "x",  and  "/", 

an  expression  is  the  current_node,  and 

the  expression  is  not  undefined 
then  "defined  node"  (procedure)  is  displayed_with_return; 

!      begin  Command      ! 

If  given  "begin"  is  the  command,  and 
given  any_node  is  the  current_node 
then  an  object  is  established  as  a  new_root; 

If  given  an  expression  is  a  new_root 
then  the  expression  is  a  root_node, 
the  expression  is  undefined,  and 
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the  expression  is  the  current_node; 
!      root  Command      ! 

If  given  "root"  is  the  command, 

given  any_node  is  the  current_node,  and 

an  expression  is  the  root_node 
then  the  expression  is  the  current_node,  and 

'!show"is  the  command; 

!     Test  driver     ! 

If  given  Nil  is  the  script 

then  "Script  completed"  (procedure)  is  displayed_with_return 

Else  if  given  a  list  is  the  script,  and 
(the  first  (function)  of  the  list  =   "#"| 

the  first  (function)  of  the  list  =    "val") 
then 
begin 
"  ...  "  (procedure)  is  displayed; 
the  first  (function)  of  the  rest  (function)  of  the  list 

(procedure)  is  displayed; 
the  first  (function)  of  the  list  (procedure)  is 

displayed  _with_re  turn; 
the  first  (function)  of  the  list  is  the  command, 

the  first  (function)  of  the  rest  (function)  of  the  list  is  the  argument,  and 
the  rest  (function)  of  the  rest  (function)  of  the  list  is  the  pending_script 
end_block; 

Else  if  given  a  list  is  the  script 
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then 
begin 
"  ...  "  (procedure)  is  displayed; 
the  first  (function)  of  the  list  (procedure)  is 

displayed_with_return; 
the  first  (function)  of  the  list  is  the  command,  and 
the  rest  (function)  of  the  list  is  the  pending_script 
end_plock; 

If  given  a  list  is  the  pending_script,  and 

something  is  not  the  command 
then  the  list  is  the  script; 

end_rules. 

!      activate  the  rules     ! 

The  PIl_rules  (procedure)  are  activated. 

Nil  is  the  current_node. 

"PI-1  System  loaded"  (procedure)  is  displayed _with_re turn. 
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APPENDIX  C:    Transcript  of  Q    Session 

The  following  is  a  transcript  of  an  Q  session  illustrating  the  operation  of  the  prototype  programming 
environment  shown  in  Appendix  A.  The  assertion  'Script  ( testscript) '  causes  the  commands  in 
testscript  to  be  executed  in  order.  Each  command  is  printed  on  a  separate  line,  followed  by  whatever 
output  is  generated  by  the  programming  environment.  This  transcript  was  produced  by  the  McArthur 
interpreter  i  McArthur84]  . 

OMEGA-1      11/30/84 

Use  Cntl-D  or  exit{}  to  quit. 

For  help,  enter  help{"?"}. 

To  report  a  bug,  enter  Bugs{}. 
PI-1  System  loaded 
>    Script  (testscript) . 

begin,  +,/,#,  3,  next,  #,  0,  out,  out,  in,  next,  #,  1,  root,  evaluate,  show,  in,  in,  next, 

delete,  #,  1,  root,  abort,  evaluate] 

...  begin 

...  + 

...  / 

...  3# 
3 

...  next 
<  expr> 


...  out 

(3/0) 
...  out 
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((3  /  0)   +    <  expr>  ) 

...  in 
(3/0) 

...  next 

<  expr> 

-  1# 
1 

...  root 
((3/0)  +    1) 

...  evaluate 
division  by  zero 

...  show 
(3/0) 

...  in 
3 

...  next 
0 

...  delete 

<  expr> 
...  1# 

1 

...  root 
((3/1)  +    1) 

...  abort 
aborted 

...  evaluate 
4 
Script  completed 
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>    exit{}. 
Goodbye. 
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